In a long line of enterprise architecture frameworks, TOGAF® is not the first and it’s unlikely to be the last. But it is one that’s endured for nearly two decades, with worldwide usage – an impressive feat in today’s technology landscape.
TOGAF is the acronym for The Open Group Architecture Framework and it was developed by The Open Group, a not-for-profit technology industry consortium that continues to update and reiterate the TOGAF.
This article will focus on familiarizing beginners with TOGAF.
Understanding enterprise architecture
In a previous article, we deep dived into enterprise architecture frameworks. Enterprise architecture refers to the holistic view and approach of software and other technology across an entire company, or enterprise.
Typically, enterprise architecture isn’t just a structure for organizing all sorts of internal infrastructures. Instead, the goal is to provide real solutions to business needs through analyzing, designing, planning and implementing the right technology in the right ways.
More and more, enterprise architecture also encompasses additional business needs like business process management and data analytics. The goal of an organized enterprise architecture, then, is to successfully execute business strategy with efficiency, efficacy, agility, and security.
If all this sounds like it can be complicated – designing and implementing a clear, long-term solution to all enterprise software in a way that solves business needs – it’s because it is. That’s why enterprise architecture frameworks (EAFs) started emerging informally and formally, as long as five decades ago.
TOGAF history and facts
As a subset of computer architecture, enterprise architecture as a field dates back to the mid-1960s. IBM among other companies and universities spearheaded some explicit ways to build enterprise architecture, knowing that all the pieces involved to run on a network are complicated.
Over the next few decades, technology only became more complicated: today, most companies, regardless of size or product, utilize the internet to make their business processes easier, quicker, and sometimes more transparent. Today, enterprise architecture is a necessary process to make sense of various hardware and software options, on premise and in the cloud, and to ensure security when sharing data across multiple platforms.
The TOGAF was initially developed in 1995. As was common in the field of enterprise architecture by then, newer versions or models offered improved iterations and theories. Likewise, TOGAF took a lot of inspiration from the U.S. Department of Defense’s own EAF, called the Technical Architecture Framework for Information Management, or TAFIM for short. Interestingly, the USDoD stopped using the TAFIM within a couple years of the emergence of TOGAF. Still, TOGAF implementation and success continues worldwide today, more than 20 years later.
The Open Group has updated TOGAF to the current 9.1 version, originally released in 2011. The Open Group further certifies tools and courses that meet TOGAF standards. Today various organizations have developed 8 tools and 71 courses which are officially certified by the Open Group.
The TOGAF approach to EAFs
The Open Group defines the TOGAF as the “de factor global standard for enterprise architecture”. The framework is intended to help enterprises organize and address all critical business needs through four goals:
- Ensuring all users, from key stakeholders to team members, speak the same language. This helps everyone understand the framework, content, and goals in the same way and gets the entire enterprise on the same page, breaking down any communication barriers.
- Avoiding being “locked in” to proprietary solutions for enterprise architecture. As long as the company is using the TOGAF internally and not towards commercial purposes, the framework is free.
- Saving time and money and utilizing resources more effectively.
- Achieving demonstrable return on investment (ROI).
3 Pillars of TOGAF
If the four goals are the theoretical outcome of using TOGAF, then the three pillars are the way to achieve the goals. These pillars help create a systematic process to organize and put software technology to use in a structured way that aligns with governance and business objectives. Because software develop relies on collaboration across various business departments inside and outside of IT, TOGAF’s goal of speaking the same language encourages and assists the various stakeholders to get on the same page, something that may not otherwise happen in business environments.
The TOGAF is divided into three main pillars:
- Enterprise architecture domains. These divide the architecture into four key areas, (sometimes shortened to ‘BDAT areas’):
- Business architecture, which defines business strategy and organization, key business processes, and governance and standards.
- Applications architecture, which provides a blueprint for deploying individual systems, including the interactions among application systems as well as their relationships to essential business processes.
- Data architecture, which documents the structure of logical and physical data assets and any related data management resources.
- Technical architecture (also known as technology architecture), which describes the hardware, software, and network infrastructure necessary to support the deployment of mission-critical applications.
- Architecture Development Model (ADM). This iterative cycle uses performance engineering to develop an actual enterprise architecture. Importantly, it can be customized to the enterprise’s needs, so it’s not a one-size-fits-all approach. Once an architecture is developed, the enterprise can roll it out to all teams or departments in iterative cycles, ensuring minimal errors and further helping the company communicate cohesively.
- Enterprise Continuum. This classification system tracks architecture solutions on a range, starting at generic, industry-standard options and including customized enterprise-specific solutions.
Proponents say that ADM is the heart of TOGAF – it’s this pillar that makes TOGAF both very effective and a standout from other frameworks. The Architecture Development Method offers eight steps as guidance to figure out where the enterprise currently is and determine where the enterprise wants and needs to be in each of the four enterprise architecture domains.
Once business processes are established through the entire lifecycle, the ADM helps the enterprise identify the gaps between current status and long-term goals, and then collates these gaps into smaller actionable and understandable packages that the team can then implement.
Two other areas are sometimes included in TOGAF’s main pillars: TOGAF certified tools and qualifications.
The Open Group offers two certifications for individuals: the first level is known as the Foundation, teaching basic tenets of enterprise architecture and rolling out TOGAF, and Level 2 Certified involves business analysis and application. The Open Group also certifies tools that align with TOGAF. For the most recent version, eight tools from eight organization are available.
Benefits of using TOGAF
The benefits of ADM are that it is customizable to organizational need – there’s no need to create a structure that doesn’t serve your business. These smaller packages are also scalable, so if one team rolls it out, it can successfully be rolled out to other teams without much tweaking. This helps the enterprise establish a process with multiple check points, so that there are few errors the wider the architecture is implemented.
There can also be benefits to individuals who certify in TOGAF. A study of industry employees indicates that enterprise architects, software architects, and IT directors, among others, who choose to earn a certification in TOGAF often see an average yearly pay bump of $10,000 – $20,000 over similarly placed colleagues who aren’t certified.
Some experts in enterprise architecture point out that while TOGAF may appear very logical, it’s actually quite a shake up to traditionally educated technology consultants today – but perhaps this will change has TOGAF adoption continues along steadily.
Success and Criticism
According to the Open Group, TOGAF is employed in more than 80 percent of Global 50 companies and more than 60 percent of Fortune 500 companies. Though criticism of the framework is often that it is too complicated or theoretical to be applicable, it seems that plenty of companies are using the structure.
Companies who have successfully implemented the framework admit that failings do happen, because TOGAF cannot be a cure all for enterprise issues. While the issue can be TOGAF principles or the enterprise architecture itself, others argue that sometimes key stakeholders and C-level management don’t always take the time to set up important factors, such as key performance indicators (KPIs), to make the architecture team successful.
This lack of complete buy-in may sometimes be due to the complicated nature of TOGAF, when looked at in its entirety. Indeed, even when the framework feels overwhelming, the best advice may be to pick what works best for your company. Some technology experts suggest precisely that: skip what seems overdone or unnecessary and implement the pieces that seem most necessary. After all, the key stakeholders are the ones who need to find use in this structure, and they know the company the best.
Many understand that TOGAF is a work in progress – marked by new releases every few years. Even skeptics of TOGAF and enterprise architecture frameworks in general find that the applied use of TOGAF is often successful simply because it is better than doing nothing.
When companies want to jump onboard a new technology, it often requires building out the right tech team from scratch and then tracking down all sorts of data. It gets messy – and the rapid pace that technology shifts and improves, these requests occur a lot more often than they used to. This can explain, in part, the bustling IT and architecture teams that are always busy yet somehow always seem behind.
TOGAF is no miracle tool, but it does provide structure to help these teams – and upper-level management – from having to reinvent the wheel each time the company wants to incorporate new technology.
One technology expert, Jason Bloomberg, underscores why TOGAF is such a conflicting topic in the enterprise architecture industry. When organizations employ TOGAF, they typically “fall into four buckets”: those who apply it incorrectly, and therefore show no value; those who achieve some baseline success in handling legacy problems; those who achieve explicit business goals; and those who want to handle change better overall. This final group sees enterprise architecture as a way to become more agile.
As its widespread use indicates, TOGAF can help enterprises of any size and any industry – but those who employ it are probably best served by understanding its pros and cons first, and then applying the parts that make particular sense for their own company.
